-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
read tickets #132
read tickets #132
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@graydon Was this ready to merge and we forgot to review / merge it?
@leighmcculloch my understanding of this PR was that it was a proof-of-concept, but we weren't going to review it until after the current iteration. @graydon correct me if I'm wrong. |
Yeah this is a "come back to it in next iteration" change. I think it's roughly the right shape (given the ugly problem space) but there's a little care required and it doesn't really block anything just yet. |
possibly ticket numbers should be "the next free object handle", and we can integrate this work with #681 |
Setting target milestone to |
Continuing in #930 |
This is a WIP implementation of "read tickets", a mechanism for associating read permissions with objects and enforcing that only context frames granted access to an object can read it. It doesn't currently perform the permission-transfer necessary when handing an object handle from a contract caller to callee, so at the moment it completely isolates objects allocated by frame X from those allocated by frame Y, but I'll finish this up tomorrow to allow such transfers.
I think this is about the cheapest/simplest way to enforce this sort of thing. I sketched a few designs based on frame-local aliases / forwarding proxies and they just wind up messier and using more memory & CPU. Most of the time this just adds ~2 words to every object and does a couple bitmask tests.